The settings page Hamlib tab was showing red/NOK even when the radio
was connected, due to several issues:

- SetupPageHamLib had a local HamLibClass instance for testing that
  competed with the live MainWindow connection, causing interference
  and state confusion.  Replace with a single-connection design: all
  operations use the live hamlib passed in via setLiveHamlib().

- stopHamlib() was called by SetupDialog on every OK/Cancel click,
  killing the live radio connection.  Now a no-op since the live
  connection is owned by MainWindow.

- setTestResult() used QPalette for button colouring; GTK/system themes
  on Linux override palette on disabled buttons, making a green button
  appear red.  Replaced with explicit stylesheets covering :disabled.

- loadSettings() triggered slotRadioComboBoxChanged() via setRigType(),
  which called setTestResult(false) on every dialog show.  Fixed with
  blockSignals() around programmatic combo changes.

- Button is now disabled (greyed label irrelevant) when connected and
  re-enabled when disconnected, with rigDisconnected also resetting it.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Some rigs (e.g. Kenwood TS-450S) implement rig_get_split_vfo by
physically switching to the TX VFO and back, causing the radio display
to flicker to a different band/frequency on every poll cycle — a
variant of the issue ea4k#947 fix that covered readFreq() but not
readSplit().

Probe once in init() after rig_open() succeeds: read frequency, call
rig_get_split_vfo, read frequency again. If it changed the rig's
backend switches VFOs for this query; restore via rig_set_vfo and
disable split polling for the session so normal operation is never
disturbed. Rigs that handle the query without side-effects continue
to have split polling enabled.

Also add a memory-channel guard in readSplit(): when currentVfo is
RIG_VFO_MEM split is not applicable and the query would cause the
same VFO-switching side-effect.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Use 4 decimal places when formatting the frequency label so that
frequencies like 5.3685 MHz are shown correctly rather than being
rounded to 5.369 MHz.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Two fixes for the case where KLog and another application (e.g. FreeDV)
share the same rigctld instance:

1. readVFO(): only permanently disable vfoQuerySupported for
   RIG_ENAVAIL/RIG_ENIMPL (rig doesn't support the call).  Transient
   errors (rigctld busy, timeout) no longer clear currentVfo or disable
   the memory-channel guard — the last known VFO state is retained so
   readSplit() continues to skip split queries while in memory mode.

2. Split probe in init(): detect VFO side-effects using both VFO state
   and frequency comparison.  Previously only frequency was checked, so
   if rig_get_freq() failed due to rigctld contention the probe was
   inconclusive and split polling remained enabled.  Adding VFO change
   detection covers that case.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

When the connection status goes NOK (e.g. transient rigctld failure at
startup while another application holds the lock), the checkbox was
being unchecked programmatically.  The OK path only re-enabled it, not
re-checked it, so after a Test success the checkbox stayed unchecked and
hamlib remained disabled without the user realising.

The activation checkbox represents user intent (do you want hamlib?),
not the current connection state — the Test: NOK button already
communicates the failure, and setEnabled(false) grays the checkbox out.
Remove the setChecked(false) so the user's preference is preserved
across transient connection failures.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Reduces cyclomatic complexity of init() by moving the split VFO
side-effect probe into a dedicated private method.  No behaviour change.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…laces

The defaultFreqMode placeholder displayed before the rig connects used
"000.000 / Mode" (3 decimal places), inconsistent with the 4-decimal
format used for live radio frequencies.  Update to "000.0000 / Mode".

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>